home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0252.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.6 KB  |  66 lines
  1. It does _not_ mean that all 8-bit data has to be base64 encoded. 8bit
  2. is a perfectly valid Content-Transfer-Encoding, if you're using FTP or
  3. WAIS or some other 8-bit-clean transport mechanism. But if you're
  4. using email or HTTP, base64 solves the issue quite neatly.
  5.  
  6. Nor does it mean that all documents look like RFC-822 messages.
  7. Messages is one _type_ of MIME body part. The text/plain type covers
  8. plain text documents. Image/gif is good for lots of pictures.
  9. Application/postscript covers printer-ready stuff. Unknown data can be
  10. tagged application/octet-stream. And you can use types starting with
  11. "x-" for experimental private types.
  12.  
  13.  
  14. WWW should use typed links, either implicitly or explicitly. For example,
  15. client software can infer the type of a link to a USENET news article
  16. to be message/rfc-822. But it should not assume that a link to a file
  17. on an FTP server is text! That link should include the type of the
  18. data so that the client software can process it intelligently. There's
  19. already quite a bit of this going on in the WWW browser code. The MIME
  20. semantics are just a way to formalize it with the possibility of
  21. interoperating with other systems.
  22.  
  23. For example, if an anchor that points to a postscript format document
  24. should look like:
  25.  
  26. <A href="http://info.cern.ch/hypertext/foo.ps"
  27. type="application/postscript"> here is a postscript file.</A>
  28.  
  29. I wrote a proposal to recast the whole syntax of URLs so that the
  30. above sample would look more like:
  31.  
  32. <A><HTTP host="info.cern.ch" path="hypertext/foo.ps"
  33.          type="application" subtype="postscript">
  34. here is a postscript file.</A>
  35.  
  36. The ideas is that we've already got some sort of SGML parser: why not
  37. let it do the work of parsing the URL too? We could use SGML features
  38. for certain semantics; we could use the SGML numeric character entity
  39. reference ({) in stead of the %FF quoting scheme, and we could
  40. use attribute default values to infer type, subtype, and other
  41. attributes.
  42.  
  43. I also think we should have optional identity information in the
  44. links. This allows clients to determine whether two links point to the
  45. same information. For example, someone might extend some FTP an WAIS
  46. servers to return the MD5 signature of documents. Then a client could
  47. conclude (with some very high probability) that
  48.  
  49. <ftp host="cs.utexas.edu" path="contrib" name="x.tar.Z" md5="abcdef">
  50.  
  51. and
  52.  
  53. <wais host="quake.think.com" database="software" path="x-2.1.tar.Z"
  54.   md5="abcdef">
  55.  
  56. refer to the same release of the package.
  57.  
  58. Thoughts?
  59.  
  60. Dan
  61.  
  62. p.s. I've attached the MIME RFC below. If you've got a MIME mail UA,
  63. it should be able to bring up the text. If not, there's enough info
  64. for you to ftp the thing manually.
  65.  
  66.